The International Telecommunications Union (ITU) adopts ITU-T Recommendation H.320 (“H.320”) and ITU-T Recommendation H.323 (“H.323”) as the international standards for videoconferencing. H.320 standard allows videoconferencing over Integrated Service Digital Network (ISDN) and other circuit switched networks and services (e.g., Public Switched Telephone Network). In H.320, video bits are transmitted as frames compliant with ITU-T Recommendation H.221 (“H.221”). H.323 standard extends the H.320 standard series to handle data flow across the Internet and Local Area Networks (LANs). In H.323, video bits are transmitted as Real-Time Transport Protocol (RTP) packets. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services (RTP is defined by the Internet Engineering Task Force (IETF), and is described in RFC3550). Other packet-based video conferencing protocols that also use the RTP for media transport include Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP), and Skinny Client Control Protocol (SCCP) among others.
H.263 video stream is defined by ITU-T Recommendation H.263 (“H.263”) for video coding at low data rates. In H.263, each picture starts with a Picture Start code (PSC), which is a 22-bit word with a value of ‘0000 0000 0000 0000 1 00000’. In H.263, each picture may be divided into Group of Blocks (GOB), and each GOB may start with a Group of Block Start Code (GBSC), which is a 17-bit word with a value of ‘0000 0000 0000 0000 1’. Each GOB can be further divided into a fixed number of Macroblocks (MB). Each MB does not start with a unique identifying start code, such as the PSC or the GBSC described above.
IETF RFC2190 specifies the payload format for encapsulating H.263 bitstream in a RTP packet. In particular, for each RTP video packet, the RTP fixed header is followed by a H.263 payload header, which is followed by the H.263 compressed video bitstream. There are three modes for the H.263 payload header. Each RTP packet can use one of the three modes for the H.263 video stream depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at a GBSC or a PSC. In other words, mode A is used for packets starting with a fixed starting code: GBSC or PSC. The long H.263 payload headers (mode B and C) support fragmentation at a Macroblock (MB) boundary. Mode B and C are necessary for a GOB whose size is larger than the maximum network packet size allowed in the underlying protocol (e.g., 1500 bytes), thus making it impossible to fit one complete GOB in a packet. In the latter case, the H.263 video bits are fragmented at a MB boundary.
In the media plane of a H.320 video gateway, video bits are transported as RTP packets using one of the many packet-based signaling protocols (e.g., H.323, SIP, or MGCP) on the packet side of the gateway, and as H.221 frames using H.320 protocol on the telephony side of the gateway. When translating from H.320 protocol to a packet-based protocol at the gateway, the video bits must be fragmented at precise locations according to RFC standards, such as RFC2190. For example, the video bits may be fragmented at a PSC or a GBSC for mode A packets, or at a MB boundary for mode B and C packets. The video bitstream is searched bit-by-bit for the PSC, GBSC or the MB boundary. Finding the PSC or GBSC is a relatively low-complexity task since the PSC and GBSC are fixed values. But finding the MB boundary may require an excessive amount of processor execution time and memory on the gateway processor due to the bit-oriented processing and the variable length coding (VLC) of the H.263 scheme. In the latter case, a full H.263 decoder is required for such precise fragmentation. If the packet is fragmented arbitrarily rather than at its precise boundary location, which may happen when the gateway only implements a reduced complexity H.263 decoder to determine the fragmentation boundary, potential video impairment may occur.
Therefore, it is beneficial to provide a scheme for precise fragmentation of H.263 video bitstreams at a H.320 video gateway without over-burdening the H.320 video gateway processor with the fragmentation task.